Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-caradec-mpx-option-00.txt < prev next >

Wrap

Text File | 1993-07-07 | 19.3 KB | 582 lines

INTERNET DRAFT Jean-Philippe Caradec, Author Marjo F. Mercado, Editor Hewlett-Packard Company July 1993 TELNET MPX option Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This Internet Draft specifies a multiplexing protocol for TELNET hosts and devices using the Internet TCP/IP protocol stack. Hosts that exchange TELNET Multiplexing (MPX) information within the TELNET protocol are expected to adopt and implement this protocol. By negotiating the MPX option, both client and server agree to use the specified multiplexing protocol. This negotiation is on a per transport link basis. The goal of this option is to use a single TCP connection to link device servers and remote hosts. This link is then used to carry out multiple session traffic. The MPX protocol will be responsible for establishing sessions between TELNET client ports and TELNET server hosts. The protocol will also be responsible for doing session flow control. To handle these two functions, a header will be added to the TELNET data path specifying the session, the data-length, the flow control process and the session packet type. Document expiration date The expiration date for this Internet Draft is December 31, 1993. 1 1. Command Name and Code MPX XX 2. Command meanings IAC WILL MPX Sender is willing to send TELNET data using the session multiplexing process on the TCP connection. IAC WON'T MPX Sender refuses to use the session multiplexing process. IAC DO MPX Sender is willing to receive TELNET data using the session multiplexing process on the TCP connection. IAC DON'T MPX Sender refuses to receive TELNET data with session multiplexing encapsulation. 3. Default WON'T MPX The session multiplexing encapsulation is not used to send TELNET data. DON'T MPX The session multiplexing encapsulation is not used to receive TELNET data. 4. Motivation for the option. On most of the UNIX (R) machines implementing the ARPA protocol stack, the application traffic is character mode oriented. This implies a large number of packets containing a limited number of characters to handle either on client and server side. TELNET clients are supporting more and more sessions to a single TELNET server. Moreover, TELNET traffic can use an asynchronous link as a physical link with limited bandwidth, i.e. SLIP or PPP. To avoid an escalation in terms of performance requirements either on the client or the server side, the session multiplexing TELNET option has been defined to limit the amount of exchanged packets using a single TCP connection to carry out multiple session traffic. 2 5. Description of the TELNET option. By negotiating the MPX option, both client and server agree to use the specified multiplexing protocol. This negotiation is on a per transport link basis. The goal of this option is to use a single TCP connection to link device servers and remote hosts. This link is then used to carry out multiple session traffic. The MPX protocol will be responsible for establishing sessions between TELNET client ports and TELNET server hosts. The protocol will also be responsible for doing session flow control. To handle these two functions, a header will be added to the TELNET data path specifying the session, the data-length, the flow control process and the session packet type. 5.1 MPX header format | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 | +++++++++++++++++++++++++++++++++ +pkt type | credit |High L.| +++++++++++++++++++++++++++++++++ + Low data length + +++++++++++++++++++++++++++++++++ + local session number + +++++++++++++++++++++++++++++++++ + reserved for future usage + +++++++++++++++++++++++++++++++++ WHERE: --> The packet type can take the following values: 0 : TELNET data end session packet. 1 : TELNET data continue session packet. 2 : TELNET non-flow controlled data end session packet. 3 : start request session packet. 4 : start confirm session packet. 5 : close session packet. 6 : echo request/reply session packet. --> the credit can take values from 0 to 7. --> the (High L./Low) data length can take values from 0 to 1023. --> the session number can take values from 0 to 255. --> The reserved byte must be set to zero. 3 5.2 Session number The session number identifies the session on both sides. Both sides of the connection should have the same session number. During the start session process, this field is filled in by the caller. The session number is linked to a dedicated TCP connection to a remote host. To avoid collision on the allocated session number, the TELNET client will use the first available session number starting from 0 going to 255 whereas the TELNET server will use the first available session number starting from 255 going to 0. If a start session collision occurs on the same session number, the TELNET client will refuse the TELNET server session open whereas the TELNET server has to accept the start session from the TELNET client. This gives priority to the client start session over the server start session. 5.3 Data length field The data length specifies the user data size that can be found after the protocol header for that specific session packet. If larger packets have to be sent, the "data continue/data end" mechanism can be used to reassemble the large packet. This data length does not include the MPX header size. 5.4 Credit field The credit field can take values from 0 to 7. At session opening, both entities advertise the amount of data (the absolute credit) they can receive. The absolute credit is defined in units. A unit can be a session data packet or a subset of a session data packet if the session data packet size is larger than the unit size. Suppose that the unit size is equal to 10 bytes, a session data packet of one byte represents one unit but a session data packet of 40 bytes represents 4 units. The absolute credit represents the number of units that the entity can receive. The absolute credit is defined in the start packets. The following credits proposed in the credit field represents an incremental number of units. Credit increment can be delayed to avoid sending data packet with length equal to 0 just to increment credit. A credit increment timer can be started to favor piggy-backing of credit incremental information with data packet to send. 4 5.5 Packet type field. 5.5.1 TELNET data end session packet. This packet type will contain TELNET data including either user data or TELNET command. All the TELNET commands are supported over this mechanism. The credit increment packets have to be sent using a data end packet with data-length equal to zero. 5.5.2 TELNET data continue session packet This packet type will contain TELNET data including either user data or TELNET command. The "data continue" packet type is used when the notion of "fragment" sent over session packet is required to reassemble large reads or writes on the remote site. In that case, multiple data continue packets can be sent followed by a data end packet. 5.5.3 Start session packet. The start session packet is used to establish a session over the transport link. The start session packet contains the absolute credit value, unit size and information linked to the caller identification. The start session can be accepted or refused by the called entity. | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 | +++++++++++++++++++++++++++++++++ +pkt type | credit |High L.| +++++++++++++++++++++++++++++++++ + Low data length + +++++++++++++++++++++++++++++++++ + local session number + +++++++++++++++++++++++++++++++++ + reserved for future usage + +++++++++++++++++++++++++++++++++ + MPX data length + +++++++++++++++++++++++++++++++++ + Credit unit size (higher b.)+ +++++++++++++++++++++++++++++++++ + Credit unit size (low b.) + +++++++++++++++++++++++++++++++++ + 2 bytes reserved + +++++++++++++++++++++++++++++++++ + upper layer data lgth (h) + +++++++++++++++++++++++++++++++++ + upper layer data lgth (l) + +++++++++++++++++++++++++++++++++ + Upperlayer info + +++++++++++++++++++++++++++++++++ 5 The MPX data length represents the data length of the MPX parameters in the start session packet. Currently, that length is set to 4 (credit parameter + 2 bytes reserved). The upper layer information follows the MPX parameter fields. The upper layer data length field has to be calculated by adding the fixed header size plus one byte for the MPX data length field plus the MPX data length itself. 5.5.4 Start confirm session packet. The start confirm session packet is sent by the called TELNET device to accept the session opening. No session data must be sent between the start session and the start confirm. | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 | +++++++++++++++++++++++++++++++++ +pkt type | credit |High L.| +++++++++++++++++++++++++++++++++ + Low data length + +++++++++++++++++++++++++++++++++ + local session number + +++++++++++++++++++++++++++++++++ + reserved for future usage + +++++++++++++++++++++++++++++++++ + MPX data length + +++++++++++++++++++++++++++++++++ + Credit unit size (higher b.)+ +++++++++++++++++++++++++++++++++ + Credit unit size (low b.) + +++++++++++++++++++++++++++++++++ + 2 bytes reserved + +++++++++++++++++++++++++++++++++ + local session number + +++++++++++++++++++++++++++++++++ + upper layer data lgth (h) + +++++++++++++++++++++++++++++++++ + upper layer data lgth (l) + +++++++++++++++++++++++++++++++++ + Upperlayer info + +++++++++++++++++++++++++++++++++ The same convention as start session packet is used for start confirm packet fields. 6 5.5.5 Close session packet. The close session packet is sent for two reasons. The called entity specifies that the session is refused or the session is ended by one of the entities. | 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 | +++++++++++++++++++++++++++++++++ +pkt type | credit |High L.| +++++++++++++++++++++++++++++++++ + Low data length + +++++++++++++++++++++++++++++++++ + local session number + +++++++++++++++++++++++++++++++++ + reserved for future usage + +++++++++++++++++++++++++++++++++ + MPX data length + +++++++++++++++++++++++++++++++++ + MPX close reason + +++++++++++++++++++++++++++++++++ When all sessions are closed on a TCP link, the link must be disconnected. The MPX data length value is currently one because the only MPX field is the close reason. The close reason can take multiple values: 1 : session closed by user. 2 : session closed on modem down. 3 : session closed on reset. 4 : session closed by upper layer. 5 : session closed by TELNET server. 5.5.6 Non-flow controlled data session packet. The non-flow controlled data packet is used to bypass normal data path for urgent delivery. There is no non-flow controlled data continue session packet. 5.5.7 Echo request/reply. The echo request/reply packet is used to determine the network delay between the TELNET client and the TELNET server. After the link is established, an echo packet is sent requesting from the server an immediate reply. The time measurement between the request and the reply is then computed to optimize the multiplexing timer (see next sections). The data length is null and the echo request/reply packet is not subject to flow-control (no credit unit is consumed to send the echo request/reply session packet). 7 5.6 Multiplexing session over a transport connection. The multiplexing algorithm is based on a multiplexing timer which concatenates the traffic of multiple TELNET sessions. The multiplexing timer can take values from 10 to 120 ms. The recommended value on client side is 80 ms and on server side 10/20 ms. These values are appropriate for interactive traffic. When the multiplexing timer pops, TELNET data is collected from multiple sessions. Before each session user data, the 4 byte protocol header is added. The data length field of each session data permits the demultiplexing process to occur. 6. Implementation issues. The MPX protocol implies an encapsulation of the user data within a session packet. This new mode is enabled once the TELNET MPX option is negotiated between the two entities. To avoid mixing TELNET packets with and without headers, we expect that any TELNET device implementing MPX option will start its TELNET negotiation with the MPX option negotiation. Further TELNET negotiation occurs once the session is established. The multiplexing timer value needs to be dynamically adapted to any echo delay modification to favor echo response time. The echo request packet should be sent every 10 seconds to test response time depending on IP network routes. If traffic is rerouted because of router failure, the timer should be automatically updated to offer the best echo delay/performance compromise. 8 7. Example users client server user1 "connect" ------ TCP SYN -------------> <-- TCP SYN/ACK --------- -------TCP ACK --------> <-- IAC WILL/DO MPX ____________ -- IAC WILL/DO MPX ____________> ------- start session --> <-------start confirm ----------- <------ [ TELNET neg ] ---------- ------- [ TELNET neg ] ---------> user2 "connect" ------- start session ---------> <-------start confirm ----------- <------ [ TELNET neg ] ---------- ------- [ TELNET neg ] ---------> user1 data | | user2 data |-> -----<header1>data1<header2>data2 --> 8. Reference [1] Postel, J., and J. Reynolds, "TELNET PROTOCOL SPECIFICATION", RFC 854, USC Information Science Institute, May 1983 9 9. Author's Address Jean-Philippe Caradec Grenoble Networks Division Hewlett Packard France 5, Rue Raymond Chanas 38320 Eybens France Phone: +33 76625518 Email: caradec@gnlab030.grenoble.hp.com Marjo F. Mercado Grenoble Networks Division - Cupertino Hewlett Packard Company 19420 Homestead Road, MS 43 LH Cupertino, CA 95014 U.S.A. Phone: (408) 447-2826 Email: marjo@cup.hp.com Document expiration date The expiration date for this Internet Draft is December 31, 1993. 10